I have not yet tested this myself, as I first wanted to know if anything else is needed here.

I am in process of building the z-stack library with hardware flow control, but need something to test with, chicken and egg. I think this exposes everything correctly to zigpy, but I wasn't 100% sure. So this is also a 'verification step' to check if this patch is correct at all.

I will report later if this works or not, where the second bit will be hardware. Is my Z-Stack patch broken, did I forget to flip the switch, or is zigpy-cli not doing it for me.

Is my Z-Stack patch broken, did I forget to flip the switch, or is zigpy-cli not doing it for me.

If you run zigpy-cli in verbose mode (zigpy -vvv), you will be able to see the radio connection parameters: "Opening a serial connection to %r (baudrate=%s, xonxoff=%s, rtscts=%s)"

So first test shows the option to be working as expected.

voluptuous.error.MultipleInvalid: value must be one of [None, 'hardware', 'software'] for dictionary value @ data['device']['flow_control']
/ # zigpy -vvv radio --baudrate=115200  --flow-control None znp /dev/ttyUSB0 form

(yes, I am aware that None wasn't a valid string to begin with, but I wanted to trigger the error/see what happens :p)

/ # zigpy -vvv radio --baudrate=115200 --flow-control=hardware znp /dev/ttyUSB0 info
2024-08-16 07:35:19.955 fb5f17fa8e36 zigpy.serial DEBUG Opening a serial connection to '/dev/ttyUSB0' (baudrate=115200, xonxoff=False, rtscts=True)

/ # zigpy -vvv radio --baudrate=115200 --flow-control=software znp /dev/ttyUSB0 info
2024-08-16 07:36:22.957 fb5f17fa8e36 zigpy.serial DEBUG Opening a serial connection to '/dev/ttyUSB0' (baudrate=115200, xonxoff=True, rtscts=False)

It doesn't work yet for me (other then none, the default) as my firmware does not yet handle hardware flow control; and doesn't support software flow control at all anyway (so it just hangs, which is expected).

The commands get forwarded and interpreted properly however.

Not sure if it helps much waiting for the hardware flow control firmware, as any problems would be in znp or the firmware, not zigpy-cli. But feel free to wait for it.

I think this is more explicit. There's various option, but the only accepted flag is passed. No room for ambiguity. Upstream does something similar as well anyway.

rtscts and xonxoff are only really used by the serial port library. Zigpy only uses hardware and software (and none).

They can always run --help, the options are all listed there. I'm not a fan of aliases like this, especially for development tools.

They can always run --help, the options are all listed there. I'm not a fan of aliases like this, especially for development tools.

While I generally agree with you; I think here it does make sense to alias the values, to go with the common namings. Which is what zigpy itself even does; rename hardware to rtscs.

However, you are the boss; so I'll drop the aliases.